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Channel Bindings for TLS 


Abstract 


This document defines three channel binding types for Transport Layer 
Security (TLS), tls-unique, tls-server-end-point, and tls-unique-for- 
telnet, in accordance with RFC 5056 (On Channel Binding). 
Note that based on implementation experience, this document changes 
the original definition of ’tls-unique’ channel binding type in the 
channel binding type IANA registry. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5929. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 
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1. Introduction 


Subsequent to the publication of "On Channel Bindings" [RFC5056], 
three channel binding types for Transport Layer Security (TLS) were 
proposed, reviewed, and added to the IANA channel binding type 
registry, all in accordance with [RFC5056]. Those channel binding 
types are: ’tls-unique’, ’tls-server-end-point’, and ’tls-unique-for- 
telnet’. It has become desirable to have these channel binding types 
re-registered through an RFC so as to make it easier to reference 
them, and to correct them to describe actual implementations. This 
document does just that. The authors of those three channel binding 
types have transferred, or have indicated that they will transfer, 
"ownership" of those channel binding types to the IESG. 


We also provide some advice on the applicability of these channel 
binding types, as well as advice on when to use which. Additionally, 
we provide an abstract API that TLS implementors should provide, by 
which to obtain channel bindings data for a TLS connection. 


WARNING: it turns out that the first implementor implemented and 
deployed something rather different than what was described in the 
IANA registration for ’tls-unique’. Subsequently, it was decided 
that we should adopt that form of ’tls-unique’. This means that this 
document makes a backwards-incompatible change to ’tls-unique’. See 
Section 8 for more details. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


3. The ’tls-unique’ Channel Binding Type 


IANA updated the registration of the ’tls-unique’ channel binding 
type to match the description below. There are material and 
substantial changes from the original registration, both in the 
description as well as registration meta-data (such as registration 
ownership). 


3.1. Description 


Description: The first TLS Finished message sent (note: the Finished 
struct, not the TLS record layer message containing it) in the most 
recent TLS handshake of the TLS connection being bound to (note: TLS 
connection, not session, so that the channel binding is specific to 
each connection regardless of whether session resumption is used). 
If TLS renegotiation takes place before the channel binding 
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operation, then the first TLS Finished message sent of the latest/ 
inner-most TLS connection is used. Note that for full TLS 
handshakes, the first Finished message is sent by the client, while 
for abbreviated TLS handshakes (session resumption), the first 
Finished message is sent by the server. 


WARNING: The definition, security, and interoperability 
considerations of this channel binding type have changed since the 
original registration. Implementors should read the document that 
last updated this registration for more information. 


Interoperability note: 


This definition of ’tls-unique’ means that a channel’s bindings 
data may change over time, which in turn creates a synchronization 
problem should the channel’s bindings data change between the time 
that the client initiates authentication with channel binding and 
the time that the server begins to process the client’s first 
authentication message. If that happens, the authentication 
attempt will fail spuriously. 


Based on the fact that while servers may request TLS 
renegotiation, only clients may initiate it, this synchronization 
problem can be avoided by clients and servers as follows: server 
applications MUST NOT request TLS renegotiation during phases of 
the application protocol during which application-layer 


authentication occurs. Client applications SHOULD NOT initiate 
TLS renegotiation between the start and completion of 
authentication. 


The rationale for making the server behavior a requirement while 
the client behavior is only a recommendation is that there 
typically exist TLS APIs for requesting renegotiation on the 
server side of a TLS connection, while many client TLS stacks do 
not provide fine-grained control over when TLS renegotiation 
occurs. 


Application protocols SHOULD be designed in such a way that a 
server would never need to request TLS renegotiation immediately 
before or during application-layer authentication. 
3.2. Registration 
o Channel binding unique prefix: tls-unique 


o Channel binding type: unique 


o Channel type: TLS [RFC5246] 
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o Published specification: <RFC 5929> 

o Channel binding is secret: no 

o Description: <See specification> 

o Intended usage: COMMON 

o Person and email address to contact for further information: Larry 


Zhu (larry.zhu@microsoft.com), Nicolas Williams 
(Nicolas.Williams@oracle.com). 


o Owner/Change controller name and email address: IESG. 


o Expert reviewer name and contact information: IETF TLS WG 
(tls@ietf.org, failing that, ietf@ietf.org) 


o Note: see the published specification for advice on the 
applicability of this channel binding type. 


4. The ’tls-server-end-point’ Channel Binding Type 


IANA updated the registration of the ’tls-server-end-point’ channel 
binding type to match the description below. Note that the only 
material changes from the original registration are: the "owner" (now 
the IESG), the contacts, the published specification, and a note 
indicating that the published specification should be consulted for 
applicability advice. References were added to the description. All 
other fields of the registration are copied here for the convenience 
of readers. 


4.1. Description 


Description: The hash of the TLS server's certificate [RFC5280] as it 
appears, octet for octet, in the server’s Certificate message. Note 
that the Certificate message contains a certificate_list, in which 
the first element is the server’s certificate. 


The hash function is to be selected as follows: 


o if the certificate’s signatureAlgorithm uses a single hash 
function, and that hash function is either MD5 [RFC1321] or SHA-1 
[RFC3174], then use SHA-256 [FIPS-180-3]; 


o if the certificate’s signatureAlgorithm uses a single hash 
function and that hash function neither MD5 nor SHA-1, then use 
the hash function associated with the certificate’s 
signatureAlgorithm; 
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o if the certificate’s signatureAlgorithm uses no hash functions or 
uses multiple hash functions, then this channel binding type’s 
channel bindings are undefined at this time (updates to is channel 
binding type may occur to address this issue if it ever arises). 

The reason for using a hash of the certificate is that some 

implementations need to track the channel binding of a TLS session in 

kernel-mode memory, which is often at a premium. 
4.2. Registration 

o Channel binding unique prefix: tls-server-end-point 

o Channel binding type: end-point 

o Channel type: TLS [RFC5246] 

o Published specification: <RFC 5929> 

o Channel binding is secret: no 

o Description: <See specification> 

o Intended usage: COMMON 

o Person and email address to contact for further information: Larry 
Zhu (larry.zhu@microsoft.com), Nicolas Williams 
(Nicolas.Williams@oracle.com). 


o Owner/Change controller name and email address: IESG. 


o Expert reviewer name and contact information: IETF TLS WG 
(tls@ietf.org, failing that, ietf@ietf.org) 


o Note: see the published specification for advice on the 
applicability of this channel binding type. 


5. The ’tls-unique-for-telnet’ Channel Binding Type 


IANA updated the registration of the ’tls-unique-for-telnet’ channel 
binding type to match the description below. Note that the only 
material changes from the original registration are: the "owner" (now 
the IESG), the contacts, the published specification, and a note 
indicating that the published specification should be consulted for 
applicability advice. The description is also clarified. We also 
moved the security considerations notes to the security 
considerations section of this document. All other fields of the 
registration are copied here for the convenience of readers. 
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Description 

Description: There is a proposal for adding a "StartTLS" extension to 
TELNET, and a channel binding extension for the various TELNET AUTH 
mechanisms whereby each side sends the other a "checksum" (MAC -- 
message authentication code) of their view of the channel’s bindings. 
The client uses the TLS Finished messages (note: the Finished struct) 
sent by the client and server, each concatenated in that order and in 
their clear text form, of the first TLS handshake to which the 
connection is being bound. The server does the same but in the 
opposite concatenation order (server, then client). 

Registration 

o Channel binding unique prefix: tls-unique-for-telnet 

o Channel binding type: unique 

o Channel type: TLS [RFC5246] 

o Published specification: <RFC 5929> 

o Channel binding is secret: no 

o Description: <See specification> 

o Intended usage: COMMON 

o Person and email address to contact for further information: Jeff 
Altman (jaltman@secure-endpoints.com), Nicolas Williams 


(Nicolas.Williams@oracle.com). 


o Owner/Change controller name and email address: IESG. 


o Expert reviewer name and contact information: IETF TLS WG 
(tls@ietf.org, failing that, ietf@ietf.org) 


o Note: see the published specification for advice on the 
applicability of this channel binding type. 


Applicability of TLS Channel Binding Types 


The ’tls-unique-for-telnet’ channel binding type is only applicable 
to TELNET [RFC0854] and is available for all TLS connections. 


The ’tls-unique’ channel binding type is available for all TLS 
connections, while ’tls-server-end-point’ is only available when TLS 
cipher suites with server certificates are used, specifically: cipher 


Altman, et al. Standards Track [Page 7] 


RFC 5929 TLS Channel Bindings July 2010 


suites that use the Certificate handshake message, which typically 
involve the use of PKIX [RFC5280]. For example, ’tls-server-end- 

point’ is available when using TLS ciphers suites such as (this is 
not an exhaustive list): 


O TLS_DHE_DSS_WITH_* 


O TLS_DHE_RSA_WITH_* 


Oo TLS_DH_DSS_WITH_* 


Oo TLS_DH_RSA_WITH_* 


Oo TLS_ECDHE_ECDSA_WITH_* 


O TLS_ECDHE_RSA_WITH_* 


Oo TLS_ECDH_ECDSA_WITH_* 


O TLS_ECDH_RSA_WITH_* 


O TLS_RSA_PSK_WITH_* 


Oo TLS_RSA_WITH_* 


O TLS_SRP_SHA_DSS_WITH_* 


O TLS_SRP_SHA_RSA_WITH_* 


but is not available when using TLS cipher suites such as (this is 
not an exhaustive list): 


O TLS_DHE_PSK_WITH_* 


o TLS_DH_anon_WITH_* 


Oo TLS_ECDHE_PSK_WITH_* 


Oo TLS_ECDH_anon_WITH_* 


Oo TLS_KRB5_WITH_* 


O TLS_PSK_WITH_* 


O TLS_SRP_SHA_WITH_* 
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'tls-server-end-point’ is also not applicable for use with OpenPGP 
server certificates [RFC5081] [RFC4880] (since these don’t use the 
Certificate handshake message). 


Therefore, ’tls-unique’ is applicable to more contexts than ’tls- 
server-end-point’. However, ’tls-server-end-point’ may be used with 
existing TLS server-side proxies ("concentrators") without 
modification to the proxies, whereas ’tls-unique’ may require 
firmware or software updates to server-side proxies. Therefore there 
may be cases where ’tls-server-end-point’ may interoperate but where 
'tls-unique’ may not. 


Also, authentication mechanisms may arise that depend on channel 
bindings to contribute entropy, in which case unique channel bindings 
would always have to be used in preference to end-point channel 
bindings. At this time there are no such mechanisms, though one such 
SASL mechanism has been proposed. Whether such mechanisms should be 
allowed is out of scope for this document. 


For many applications, there may be two or more potentially 
applicable TLS channel binding types. Existing security frameworks 
(such as the GSS-API [RFC2743] or the SASL [RFC4422] GS2 framework 
[RFC5801]) and security mechanisms generally do not support 
negotiation of channel binding types. Therefore, application peers 
need to agree a priori as to what channel binding type to use (or 
agree to rules for deciding what channel binding type to use). 


The specifics of whether and how to negotiate channel binding types 
are beyond the scope of this document. However, it is RECOMMENDED 
that application protocols making use of TLS channel bindings, use 
'tls-unique’ exclusively, except, perhaps, where server-side proxies 
are common in deployments of an application protocol. In the latter 
case an application protocol MAY specify that ’tls-server-end-point’ 
channel bindings must be used when available, with ’tls-unique’ being 
used when ‘/tls-server-end-point’ channel bindings are not available. 
Alternatively, the application may negotiate which channel binding 
type to use, or may make the choice of channel binding type 
configurable. 


Specifically, application protocol specifications MUST indicate at 
least one mandatory to implement channel binding type, MAY specify a 
negotiation protocol, MAY allow for out-of-band negotiation or 
configuration, and SHOULD have a preference for ’tls-unique’ over 
'tls-server-end-point’. 


Altman, et al. Standards Track [Page 9] 


RFC 5929 TLS Channel Bindings July 2010 


7. 


Required Application Programming Interfaces 


TLS implementations supporting the use of ’tls-unique’ and/or 'tls- 
unique-for-telnet’ channel binding types MUST provide application 
programming interfaces by which applications (clients and servers 
both) may obtain the channel bindings for a TLS connection. Such 
interfaces may be expressed in terms of extracting the channel 
bindings data for a given connection and channel binding type. 
Alternatively, the implementor may provide interfaces by which to 
obtain the initial client Finished message, the initial server 
Finished message, and/or the server certificate (in a form that 
matches the description of the ’tls-server-end-point’ channel binding 
type). In the latter case, the application has to have knowledge of 
the channel binding type descriptions from this document. This 
document takes no position on which form these application 
programming interfaces must take. 


TLS implementations supporting TLS renegotiation SHOULD provide APIs 
that allow applications to control when renegotiation can take place. 
For example, a TLS client implementation may provide a "callback" 
interface to indicate that the server requested renegotiation, but 
may not start renegotiation until the application calls a function to 
indicate that now is a good time to renegotiate. 


Description of Backwards-Incompatible Changes Made Herein to 
'tls-unique’ 


The original description of ’tls-unique’ read as follows: 


|OLD| Description: The client’s TLS Finished message (note: the 
|OLD| Finished struct) from the first handshake of the connection 
| OLD | (note: connection, not session, so that the channel binding 
|OLD| is specific to each connection regardless of whether session 
|OLD| resumption is used). 


Original ‘tls-unique’ description 


In other words: the client’s Finished message from the first 
handshake of a connection, regardless of whether that handshake was a 
full or abbreviated handshake, and regardless of how many subsequent 
handshakes (renegotiations) might have followed. 


As explained in Section 1, this is no longer the description of ‘tls- 
unique’, and the new description is not backwards compatible with the 
original except in the case of TLS connections where: a) only one 
handshake has taken place before application-layer authentication, 
and b) that one handshake was a full handshake. 
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9. 


10. 


This change has a number of implications: 


o Backwards-incompatibility. It is possible that some 
implementations of the original /tls-unique’ channel binding type 
have been deployed. We know of at least one TLS implementation 
that exports ’tls-unique’ channel bindings with the original 
semantics, but we know of no deployed application using the same. 
Implementations of the original and new ’tls-unique’ channel 
binding type will only interoperate when: a) full TLS handshakes 
are used, and b) TLS renegotiation is not used. 


o Security considerations -- see Section 10. 


o Interoperability considerations. As described in Section 3, the 
new definition of the ’tls-unique’ channel binding type has an 
interoperability problem that may result in spurious 
authentication failures unless the application implements one or 
both of the techniques described in that section. 


IANA Considerations 


IANA updated three existing channel binding type registrations. See 
the rest of this document. 


Security Considerations 


The Security Considerations sections of [RFC5056], [RFC5246], and 
[RFC5746] apply to this document. 


The TLS Finished messages (see Section 7.4.9 of [RFC5246]) are known 
to both endpoints of a TLS connection and are cryptographically bound 
to it. For implementations of TLS that correctly handle 
renegotiation [RFC5746], each handshake on a TLS connection is bound 
to the preceding handshake, if any. Therefore, the TLS Finished 
messages can be safely used as a channel binding provided that the 
authentication mechanism doing the channel binding conforms to the 
requirements in [RFC5056]. Applications utilizing ’tls-unique’ 
channel binding with TLS implementations without support for secure 
renegotiation [RFC5746] MUST ensure that ChangeCipherSpec has been 
used in any and all renegotiations prior to application-layer 
authentication, and MUST discard any knowledge learned from the 
server prior to the completion of application-layer authentication. 


The server certificate, when present, is also cryptographically bound 
to the TLS connection through its use in key transport and/or 
authentication of the server (either by dint of its use in key 
transport, by its use in signing key agreement, or by its use in key 
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10. 


10 


agreement). Therefore, the server certificate is suitable as an end- 
point channel binding as described in [RFC5056]. 


1. Cryptographic Algorithm Agility 


The ’tls-unique’ and ‘’tls-unique-for-telnet’ channel binding types do 
not add any use of cryptography beyond that used by TLS itself. 
Therefore, these two channel binding types add no considerations with 
respect to cryptographic algorithm agility. 


The ’tls-server-end-point’ channel binding type consists of a hash of 
a server certificate. The reason for this is to produce manageably 
small channel binding data, as some implementations will be using 
kernel-mode memory (which is typically scarce) to store these. This 
use of a hash algorithm is above and beyond TLS’s use of 
cryptography, therefore the ’tls-server-end-point’ channel binding 
type has a security consideration with respect to hash algorithm 
agility. The algorithm to be used, however, is derived from the 
server certificate’s signature algorithm as described in Section 4.1; 
to recap: use SHA-256 if the certificate signature algorithm uses MD5 
or SHA-1, else use whatever hash function the certificate uses 
(unless the signature algorithm uses no hash functions or more than 
one hash function, in which case ’tls-server-end-point’ is 
undefined). The construction of ’tls-server-end-point’ channel 
bindings is not directly hash-agile (since no negotiation of hash 
function is provided for), but it is hash-agile nonetheless. The 
hash agility of ’tls-server-end-point’ channel bindings derives from 
PKIX and TLS. 


Current proposals for randomized signatures algorithms [RHASH] 
[NIST-SP.800-106.2009] use hash functions in their construction -- a 
single hash function in each algorithm. Therefore, the ’tls-server- 
end-point’ channel binding type should be available even in cases 
where new signatures algorithms are used that are based on current 
randomized hashing proposals (but we cannot guarantee this, of 
course). 


-2. On Disclosure of Channel Bindings Data by Authentication 


Mechanisms 


When these channel binding types were first considered, one issue 
that some commenters were concerned about was the possible impact on 
the security of the TLS channel, of disclosure of the channel 
bindings data by authentication mechanisms. This can happen, for 
example, when an authentication mechanism transports the channel 
bindings data, with no confidentiality protection, over other 
transports (for example, in communicating with a trusted third 
party), or when the TLS channel provides no confidentiality 
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protection and the authentication mechanism does not protect the 
confidentiality of the channel bindings data. This section considers 
that concern. 


When the TLS connection uses a cipher suite that does not provide 
confidentiality protection, the TLS Finished messages will be visible 
to eavesdroppers, regardless of what the authentication mechanism 
does. The same is true of the server certificate which, in any case, 
is generally visible to eavesdroppers. Therefore we must consider 
our choices of TLS channel bindings here to be safe to disclose by 
definition -- if that were not the case, then TLS with cipher suites 
that don’t provide confidentiality protection would be unsafe. 
Furthermore, the TLS Finished message construction depends on the 
security of the TLS PRF, which in turn needs to be resistant to key 
recovery attacks, and we think that it is, as it is based on HMAC, 
and the master secret is, well, secret (and the result of key 
exchange). 


Note too that in the case of an attempted active man-in-the-middle 
attack, the attacker will already possess knowledge of the TLS 
Finished messages for both inbound and outbound TLS channels (which 
will differ, given that the attacker cannot force them to be the 
same). No additional information is obtained by the attacker from 
the authentication mechanism’s disclosure of channel bindings data -- 
the attacker already has it, even when cipher suites providing 
confidentiality protection are provided. 


None of the channel binding types defined herein produce channel 
bindings data that must be kept secret. Moreover, none of the 
channel binding types defined herein can be expected to be private 
(known only to the end-points of the channel), except that the unique 
TLS channel binding types can be expected to be private when a cipher 
suite that provides confidentiality protection is used to protect the 
Finished message exchanges and the application data records 
containing application-layer authentication messages. 
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